Description

This is a fairly major change.

https://learn.microsoft.com/en-us/dotnet/framework/performance/constrained-execution-regions#code-not-permitted-in-cers

For the longest time, and especially as part of this common project merge, we have maintained these Constrained Execution Regions as part of our netfx implementation. However, they've been a major pain to work around, since they involve try/catch/finally structures that aren't needed in netcore, or catching exceptions that are never expected to be caught in netcore. There have been several approaches brought forward to conditionally include the CER structures - some better than others. While working on the SqlCommand merge, I suggested another approach that moves the CER structure to a helper (see #3514). This uncovered a major limitation on CER blocks - that function pointers/delegates cannot be used (see link above).

This prompted a bit more research, and it appears that our codebase is riddled with code that cannot be called from a CER block. Since .NET 2.0, CER has been a guideline instead of a hard rule, and CER execution has become best-effort rather than guaranteed, and as a result much more permissive in what can be prepared/executed. Even with obvious issues in the code, CI has passed for ages, and no users have complained of faults arising from CER failures. As such, the question arises - do we even need CER anymore? The answer to this, so far, seems to be no.

So, in this PR, I searched the codebase for instances of PrepareConstrainedRegion and just removed the entire try/catch/finally structure where possible.

Here's some examples of places where we're doing unapproved things inside CER blocks:

• SqlCommand.InternalExecuteNonQuery
  • Called from SqlCommand.ExecuteNonQuery
  • Calls RunExecuteNonQueryTds which contains a lambda being called on timeout (among others)
• SqlCommand.ExecuteReader
  • Explicitly allocates the reader inside the constrained execution region
  • Uses lambdas all over
• SqlConnection.InternalOpenAsync
  • Called from SqlConnection.OpenAsync
  • Uses function pointer in retry callback
• TdsParserStateObject.ReadSniError
  • Calls TdsParserStateObject.ProcessSniPacket which explicitly allocates a byte array

This PR is best viewed with whitespace changes ignored

Issues

Will make remaining work for #1261 easier

Testing

Project still builds, CI will hopefully be sufficient for validation of behavior.